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Free Publication 


“Being a Project Manager is like being an artist, you 
have the different colored process streams combining 
into a work of art” , Greg Cimmarrusti 

This book is intended to share some best practices for 
Project RAID Management. It is a free publication to 
share and hopefully in the future it can be added to and 
improved. Please treat it a draft for discussion document 
as I hope to improve with comments from readers. 

I hope you find it useful. 

Ken Martin 

©KEN MARTIN, THIRD I CONSULTING 
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Foreword 


“Putting off an easy thing makes it hard. Putting off 
a hard thing makes it impossible ” 

- Charles E. Wilson 


The management of Risks, Issues, Assumptions and 
Dependencies (RAID) in project management is an 
ongoing challenge for most organisations. I have 
produced this short guide to bring together some of the 
best practices together. 

As with all the guides I produce, it is intended to provide 
a high-level view of these topics. The aim of this guide is 
not to go into depth on the different aspects of RAID 
management or into detail on the project management 
methodologies but just to highlight some of the RAID 
management aspects and best practices in project 
management. 

Z Also this is no one size fits all and all approaches 
need to be customized for each organization but it 
should provide a reasonable framework for going 
forward. 
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Q I have used word “Project” throughout the guide to 
avoid confusion between projects and programmes 
and to keep it simple although in many instances, 
programme would have been probably been more 
applicable. 

I hope you find the book useful in assisting your own 
RAID management in projects and if it only acts as a 
sanity check and stimulates discussion of your own 
approach, then the book will have succeeded in its aim. 

Ken Martin. Third i Consulting 

LINKEDIN: http://www.linkedin.eom/pub/ken-martin/1/24b/52b 


Ken’s Bio 


Ken has over 30 years experience in the IT industry including over 
12 years experience in financial services (payment services, 
insurance). 

Ken has had many different permanent roles during his career 
including technical specialist, development leader, VP service 
management, consultant and Project manager with employers such 
as HP, Digital, Apple, Microsoft, PWC and American Express 
including contracts with Talbots Reinsurance, Exchanging, London 
Metal Exchange, Kiln Underwriters and Marsh Insurance Brokers. 

For his Stakeholder Communications Consultancy, Ken creates IT 
change frameworks, governance processes, communication and 
training materials for previous clients on a contract basis. 

: http://third-i-communications.co.uk 

Ken is a currently a contract IT Change Manager working in London 
and the Far East. 

Knowledge Sharing Website 
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RAID Management 




“Trying to manage a project 
without project management 
is like trying to play a football 
game without a game plan.” 

— K. Tate 



RAID Management 

RAID 

- RAID is an acronym for stands for Risks, 
Assumptions, Issues, and Dependencies which is 
the “bread and butter” for a project manager. 

- Many project managers tend towards one of the 
areas (e.g.: risk management) rather giving equal 
focus to these four key areas as lack of focus on 
any one of these areas is a risk itself and can result 
in a negative affect and take a project off course. 

9 If there are actions that can be taken to avoid the 
consequences of an assumption not being true then 
it should be considered (and managed) as a risk. 

0 If an assumption cannot be changed then it should 
be considered (and managed) as a constraint 

0 If an assumption uses words like 'relies' or 
'depends' then it should be considered (and 
managed) as a dependency which in itself should be 
managed as a risk. 


Risks 


3 A risk is a possible future issue i.e. something that 
may go wrong. The definition of a risk is any specific 
event which might occur and thus have a negative 
impact on your project or program. 

w Each risk has an associated probability of 

occurrence along with an impact on your project if it 
does materialise. 

. This is the one key area that PM’s do take focus 
upon in the managing and mitigating of risks. 

Assumptions 

. The definition of an assumption is something we set 
as true to enable us to proceed with our project. 

- As part of the initial planning phase and project 
brief, assumptions are identified and documented 
but unfortunately many times they are just forgotten 
after this initial activity. 

d A common assumption in many projects is that 
there will be access to the required specialist 
resources for the duration of the project. 
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_ The purpose of tracking assumptions is that you 
need to be prepared for your assumptions being 
wrong. 

Most project plans are produced on this assumption 
but if this assumption turns out to be false then the 
project will falter. 

© It is important to include all the assumptions that 
have identified into a Project Brief. 

- Any assumptions made concerning the delivery of 
externally controlled deliverables should also be 
included. 


PRINCE 2 Definition 

A Risk is defined as uncertainty of 
outcome , whether positive opportunity 
or negative threat. 




Issues 


An issue is something that is going wrong now in a 
project are those things which has occurred, is current 
and have yet to be properly addressed. 


RAID Log Best Practices 


A general best practice is to keep 
RAID logs simple , use one 
centralised tool and to review them 
regularly at least once a week. 


For example: 

Z A risk that has gone live and requires attention 
- An unresolved question (e.g. from the Project Brief) 
„ New ideas or concerns 

w Potential changes e.g. a requirement to change a 
deliverable 
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y An unexpected event that has occurred e.g. a 
contractor going bankrupt 

- A problem that will impact on another project’s 
objectives. 

- An issue is anything which arises on your project 
which you have to deal with to ensure your project 
runs smoothly. 

© Issues differ from risks in that they exist as a 
problem today, unlike risks which might turn into 
issues in the future. 

Like risks, issues need to be managed through an 
agreed management process. 


Issues can be resolved in a number of ways, for 
example: 

* Cleared immediately with no action required 

* Additional planning undertaken and new deliverables 
added or existing deliverables changed 

¥ Issue becomes a risk, with an owner appointed and a 
countermeasure prepared. 


Dependencies 

» Dependencies are something that must be delivered 
to enable a project’s delivery and these must be 
identified and tracked as they will impact on the 
project going forward and being successful. 

Dependencies form a key part of workload 
prioritisation during the programme and are a basic 
agenda item for any meetings and decision-points 
and as such must be consistent with all other 
aspects of the plans, projects and programmes. 

© Dependencies exist when an output from one task 
or another project is needed as a mandatory input 
for another task or another project. 

© It is a key responsibility for project managers to 
record, monitor, and manage these dependencies. 

w Dependencies maybe items that are being delivered 
from elsewhere, and that may not be directly in the 
control of a project manager. 

w Dependencies being not properly managed are 
quite frequently what cause project failure. 

. The dependencies log will capture at least who the 
project is dependent upon and what they should 
deliver and when. 
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^ PM’s should also keep details of the actual 
agreement and when it was made, plus any later 
variations of this. 

RAID LOG 

Q The RAID log is a key project management tool that 
allows the stakeholders to see the progress of the 
project and issues having an impact on the 
successful implementation of a project. 

0 It is a structured, consistent tool that facilitates daily 
project management decisions and sets the agenda 
for the stakeholder meetings that will provide 
oversight of the project status and progress. 

- A RAID log is a means for managing to project 
plans, and making sure nothing falls through the 
cracks. 

0 It also acts as a source of record for the project, 
logging events as they happen. 

0 It is also monitoring tool for key important areas that 
could negatively impact the project. 

- A RAID also acts as a source of accountability as all 
risks, actions, issues and decisions are recorded 
with ownership, accountability, responsibility and 
time. 


- The RAID Log should be regularly reviewed and 
updated in the same way that the main plan is 
managed. 

Sometimes there is confusion over use of the acronym 
RAID in project management as many organisations 
who use RAID logs to manage projects have the 
following alternative meaning where RAID is an 

abbreviation for Risks, Actions, Issues and 
Decisions. 
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The Alternative RAID (Risks, Actions, 

Issues, Decisions) Log Summary 

Risks 

Q The ‘Risk’ section of the RAID Log lists all your 
identified risks, scoring each for likelihood and 
probable impact with each risk having a running log 
of mitigating actions. 

3 Your project risks are the “issues waiting to happen. 


PRINCE 2 Definition 

A " Project Issue” is a term used to 
cover any concern , query Request for 
Change , suggestion or off- 
specification raised during the project. 
They can be about anything to do 
with the project. 


^ Risk refers to the combined likelihood the event will 
occur and the impact on the project if it does occur. 

Q If the likelihood of the event happening and impact 
to the project are both high, the event is classed as 
a risk. 

- All risks should be logged no matter how small. 

3 All risks should have an ID number and all risks 
should be owned by someone who has been 
involved in the discussion about the specific risk. 

- The log includes a description of each risk, full 
analysis and a plan to manage it. 

Q In addition all risks should be measured in a 
standard way with probability and impact. 

In the risk log section, there should be columns also 
for the risk owner, status, and any dates that may 
be relevant. 

Actions 

- However detailed your project plans, PM’s will 
always have unplanned action items come up: 
follow up items, actions items from meetings, etc. 
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- So many organisations has an Actions section part 
of the RAID log to act as ‘task bucket’ to capture 
and track these items. 

- All actions are logged here from all the project 
meetings: 

¥ project boards 

¥ steering groups 

¥ risk reviews 

¥ project reviews 

¥ team meetings 

¥ technical reviews 

¥ stakeholder meetings 

¥ risk reviews 

- As with risks, all actions should have an assigned id, 
owner and timescale. 

Issues 

- An issue is something that has gone wrong 
(deviation from the approved scope, schedule, 
budget etc.) 


0 Issues are also risks that have been realised, and 
have turned into issues. 

- As with risks and actions, all issues should have an 
assigned id, owner and timescale. 

- Avoid duplication of actions with issues and the 
same actions in the actions log. 

^ Failure to manage issues may result in a poor 
delivery or even failure. 

- The log includes a description of each issue, the 
impact it is having, its seriousness and actions 
needed to contain and remove it. 

Decisions 

Q In most projects, PM’s will encounter decision 
points where the sponsor or stakeholders will make 
decisions about how the project proceeds. 

0 It is important task to record in all the project- related 
meetings, everything significant that was agreed, 
the decisions made and who and when these 
decisions were made. 

w For best practice, decisions made should be 
allocated an id number as well. 
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Risk Management 




“No one can whistle a 
symphony. It takes a whole 
orchestra 


— H.E. Luccock 


Risk Management 

The risk management process can be simplified 
according to the characteristics of the project: 

- Anticipated level of risk 

- Time 

* Resources available 

- Perceived need 

- Organizational policy 


Example IT Project Risks 

Projects often fail because of risks are not managed 
correctly. IT project risks can arise from the following. 

9 Ineffective or lack of senior sponsorship 

9 Lack of alignment with an organisation’s strategic 
objectives 

9 Lack of a valid, ongoing business case 
- Fragmented project plans 


v Poorly defined project mission and task 

- No clear process for escalating risks to senior 
management 

9 Insufficient reporting to support top management 
decisions 

9 Ineffective enforcement of project controls and 
policies 

_ Conflict between line and project managers 

9 Projects do not meet deadlines and / or milestones 

Lack of standardised reports and reporting 
frameworks 

9 Lack of clear understanding of risks when using 
new or emerging technologies 
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Successful Project Risk Management 
Factors 

. All significant risks to the success of the project are 
identified 

0 Identified risks are understood, with both the range 
of potential consequences they represent and the 
likelihood of values in that range being determined 
as far as is necessary for decision-making 

Z Assessment is undertaken of individual risks relative 
to the other risks to support priority setting and 
resource allocation 

- Strategies for treating the risks take account of 
opportunities to address more than one risk 

ZZ The process itself and the risk treatment strategies 
are implemented cost-effectively 


The Risk Management Process 

It is important to implement a risk management 

process: 

1. Establish the Context 

Establishing the context enables to create a statement 

of programme objectives and criteria for success 

The Actions 

w Review organizational and project environment 
where the risk assessment is taking place 

w Specify the main objectives and outcomes required 
of the programme 

© Identify a set of success criteria where the impacts 
of identified risks can be measured 

^ Define a set of key elements for structuring the risk 
identification and assessment process 


Outputs 

- A concise statement of the programme objectives 
2 A list of specific criteria for success 
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_ The objectives and scope for the risk assessment 

2. Identify the Risks 

This step in the process determines all the possible risks 
to a successful outcome of the project. 

- Risk identification determines what might happen 
that could affect the objectives of 
the project 

How those things might happen 

Brainstorming is a preferred method because of its 
flexibility and capability 



Outputs 

- Comprehensive list of possible risks to the 
successful outcome of the project 

3 A risk register, with risk owners allocated to 
themWho owns which project 

0 If there other projects dependent on this project 

3. Analyse the Risks 

Risk Assessment is to develop agreed priorities for the 

identified risks. 

Approach 

w Determines the consequences of each risk, should it 
arise Assesses the likelihood of those 
consequences occurring 

- Converts the consequence and likelihood ratings to 
an initial priority for the risk 

- Develops agreed risk priorities and inherent risk 
levels 

- Agreed priorities are used to determine where the 
greatest effort should be focused in treating 
identified risks 
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Z They facilitate structured action planning and 
resource allocation 

, Generates a prioritized list of risks and a detailed 
understanding of their impacts upon the success of 
the project should they occur 

© The consequence and likelihood ratings and the 
agreed risk priorities are all recorded in the risk 
register 

4.Evaluate the Risks 

Risk Assessment is to develop agreed priorities for the 

identified risks. 

Approach 

Determines the consequences of each risk, should it 
arise Assesses the likelihood of those 
consequences occurring 

Z Converts the consequence and likelihood ratings to 
an initial priority for the risk 

- Develops agreed risk priorities and inherent risk 
levels 


Z Agreed priorities are used to determine where the 
greatest effort should be focused in treating 
identified risks 

- They facilitate structured action planning and 
resource allocation 

- Generates a prioritized list of risks and a detailed 
understanding of their impacts upon the success of 
the project should they occur 

- The consequence and likelihood ratings and the 
agreed risk priorities are all recorded in the risk 
register 

5. Treat the Risks 

The purpose of risk treatment is to determine what will 

be done in response to the risks that have been 

identified to reduce the overall risk exposure. 

w Risk treatment involves identifying the options for 
reducing the likelihood or consequences of each 
(Extreme, High or Medium risk) 

w Determining the potential benefits and costs of the 
options 

- Selecting the best options for the project 
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Developing and implementing detailed Risk Action 
Plans 

- Risk Action Plan Summaries are usually required for 
each risk classified as extreme or high on the 
agreed risk priority scale 

6. Monitor and Review 

Continuous monitoring and review of risks ensures new 
risks are detected and managed, and that action plans 
are implemented and progressed effectively. 

0 The main input to this step is the risk watch list of 
the major risks that have been identified for risk 
treatment action 

Q The outcomes are as revisions to the risk register, 
and a list of new action items for risk treatment. 

7. Communicate and Consult 

Communication and consultation with project 
stakeholders may be a critical factor in undertaking good 
risk management 


© It help owners, clients and end users understand 
the risks and trade-offs that must be made in a 
large project 

- This ensures all parties are fully informed, and thus 
avoids unpleasant surprises 

~ Regular reporting is an important component of 
communication 

Q The risk register and the supporting action plans 
provide the basis for most risk reporting 

w Reports provide a summary of project risks, the 
status of treatment actions and an indication of 
trends in the incidence of risks 
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Risk Management Process 


Risk Management Process 


Responstttfity 



Establish 
the context 


1 


I \ 

I 

/ 

L/ 
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Identity 
the neks 


Analyse 
the risks 


i 


f 


Treat 
the nsks 


Monitor and 
review 




the hslts 




TYPE 1: 

Low - Medium 

Protect manager 
PM's manager 

PROJECT SUMMARY 
AMD CONTEXT 

Simple RISK RE 
RISK RE GIST 

VIEW 

ER 

Work plans 

Summary n RISK REGISTER 

RISK REGISTER 
RISK WATCH LIST 

TYPE 2 

Medium - High 

Project manager 
PM’s manager 

♦ Management 
Review 

RISK REVIEW W< 
RISK RESIST 

D-kshop 

ER 

♦ RISK ACTION PLANS 
tor Extreme and High nsks 

♦ RISK ACTION PLANS 
tor Extreme and High rsks 

TYPE 3: 
High 

♦ Risk coordinator 
(optional) 

♦ Management 
Review 

RISK REVIEW W< 
RISK REGIS1 

rkshop 

ER 

♦ RISK ACTION PLANS 
tor Extreme and High nsks 

♦ RISK MANAGEMENT 
PLAN 


Depending of the classification of the type of risk, use the .appropriate 


process and documentation 
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Risk Summary Sheet 


Risk Summary Sheet 


Key 

elements 
and issues 

No. 

Risks 

Controls 


Initial 

mority 

Agreed 

priority 

Actions and 
responsibility 

Business 

objectives 








Contractual and 
legal 








Capital 

requirements 








Resources 








Timing and 
schedule 








Technical and 
performance 








Customers 








Suppliers 








Infrastructure 









Example Risk Summary Sheet for a simplified risk assessment process 
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“No matter how good the 
team or how efficient the 
methodology, if we’re not 
solving the right problem, the 
project fails.” 

- Woody Williams 




What is an Assumption? 

Making an assumption refers to the act of taking for 
granted that something is in fact true. These are things 
what the Project Manager expects to have available to 
proceed with a project usually during early planning 
phases. Assumptions enable the project to move 
forward without absolutely certain information. 

Example Project Assumptions 

- Benefits associated with the project when building a 
business case 

- Resources will be available when and as they are 
needed 

- Stakeholders will take the necessary decisions at 
the right time 

- Required hardware resources will be available when 
and as they are needed. 

- Required business resources will be available when 
and as they are needed 

- Required third party resources will be available when 
and as they are needed 


. The resources available will have the required 
technical skills for the project 

© The way things will work within a product, issues 
often arise with integration with legacy systems 

- There will be access to subject matter experts with 
the specialized knowledge skills as needed 

© Issues will be resolved in a timely manner 

. The project organisation described in the project 
plan will be put in place 

- The figures used in preparing the budget estimates 
are accurate within a given percent 

- The scope of the project is limited to that described 
in the project brief 

3 Any changes in scope will follow an agreed change 
process 

When Do You Make Assumptions? 

During the early phases of a project, a number of 

assumptions may be made in four specific areas: 

w Business Case - when a business case is developed 
for the justification a project, there will be many 
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unknowns and assumptions that will form part the 
initial business case for the project 

- Project Scope 

- Project Schedule 

- Project Budget 



Assumption Management 

As few projects start with absolute certainty, most 
projects will be based on many assumptions. If PM’s had 
to wait for absolute certainty, most projects would never 
get off the starting block within organisations. 

- Some assumptions must be made on projects when 
there is a lack of information available to predict the 
future accurately. 

Q Experienced Project Managers do their best efforts 
to get better at making assumptions and eliminating 
as many of them as possible. 

3 As projects are planned and executed, some facts 
and issues are known, others must be estimated. 

- Project Managers can’t just hope they will have the 
necessary resources to complete a project 
successfully. 

- For example, if the required resources are not 
available, then key project milestones may be 
missed and the project will fail to achieve a 
successful outcome. 
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Project Managers need to make a brief and clear-cut 
description of any project assumptions related to: 

• business 

• people 

• technology 

• expectations 

• schedules 


The PM will document and communicate these list 
of those assumptions to key stakeholders. 

- Project Managers have to manage and mitigate 
using informed assumptions and constraints. 

y Assumptions apply at all stages of the project and 
are typically are documented at the start of a project 
and they are usually filed in a drawer and ignored. 

v Assumptions add risk to a project since it is 
possible that they will turn out to be false. 

Z Assumptions can impact any part of your project life 
cycle and resulting solution implementation, so it is 
important to document and analyse them. 


Z Assumptions usually carry implications and these 
should be documented with any resulting actions if 
they are not met. 

- Making assumptions sets benchmarks that are often 
revisited during the project to aid the project team in 
staying within scope, on time and within budget. 

An Assumption is Not a Constraint 

. Assumptions are forecasts about what may 
happen in the future, while constraints are limits on 
freedom of choice. 

- Constraints can have a negative effect on the 
project and are not ofter under the control of a PM. 

w Business constraints are a common type of 
constraint thats limit the project based upon the 
current organizational environment. 

- Constraints are usually focused around time, 
money and resources for a project. 

- When determining assumptions, it may be important 
to consider any project-related constraints as they 
may drive the identification of further assumptions 

. Constraints need be identified and incorporated into 
the project plan to ensure that the plan is realistic. 
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PM’s will need to make a description of any major 
limitations impacting a project including: 

• Budget - the estimated cost of the project, 
allocated to tasks, resources and phases as needed 
to complete the project. 

• Schedule - estimated tasks and events needed to 
complete the project, organized into a structured 
sequence to meet a specified project end date. 

• Resources - the estimated staff resources needed 
to complete the project, according to number, type, 
work hours, and skills. 

• Third Party Suppliers - the anticipated 
performance of contractors, vendors and suppliers 
to deliver goods and services according to 
contracts and project requirements. 

• Other key factors - that could affect a project 
successful outcome. 


Project Dependencies 

» Dependencies are basically deliverables from other 
projects which your project needs in order to 
launch. 

- Often dependencies get overlooked and a key 
factor why a number of projects go off track and 
miss their milestones and target dates. 

9 It’s important to determine a link between project 
assumptions and constraints and then identify any 
dependencies between them. 

- Again PM’s need to document and communicate 
the dependencies and use it in developing the 
project plan. 

Risks and Assumptions 

- The main difference between an assumption and a 
risk is that when a PM makes an assumption, the 
PM expects that assumption will happen. 

Q if the assumption is true, the project will be OK. If 
the risk happens, then the project is not OK. 
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The Danger with Assumptions 

- The key. danger specific to assumptions is that they 
become the accepted wisdom. 

v As project changes occur you may not know the 
exact impact of the change on the project. This is 
why assumptions must be managed throughout the 
project life cycle. 

^ How to Identify Assumptions 

Q The phrase “I think” occurs a number of times 
during a meeting. 

- Check the confidence level of the team in 
completing the project. Is there is a lack of 
confidence in the voices of the team when 
discussing a project. 

- Keep asking the question - what were the original 
assumptions and are there new ones? 

- Challenge all assumptions and constraints. 

- Ask If any assumption prove to be false what will be 
the consequences? 


LEAST IMPORTANT 


Assumption Criticality Matrix 

CERTAIN 


A 

A A 

A 

A 

A 

A 

A 

A 

Critical 

Region 

A 


UNCERTAIN 
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MOST IMPORTANT 




The Assumption Management Process 


1) Identify and Challenge 

. The first step in the "assumptions" management 
process is identification. 

- Collect all assumptions 

2) Assess 

J Each must be viewed with an appropriate degree of 
skepticism. 

- Quantify the assumptions as much as possible in 
order to determine which assumptions have the 
greatest impact on the pack. 

- Assumptions should be evaluated according to 
confidence level. 

3 Followed by a related If this assumption is proven 
incorrect, what will be the likely consequences for 
the project? 


3) Incorporate 

. Once assumptions are identified and assessed, they 
must be incorporated into the relevant portion of the 
project plan. 

3 Assumptions, combined with what is known, will 
drive the formation of the project plan with the 
following: 

• planned tasks 

• schedule 

• budget 

• resources 

4) Control 

„ Because assumptions have the potential to impact 
projects negatively, it is the responsibility of project 
managers to monitor and manage them. 

w PM’s stop assumptions becoming the accepted 
wisdom by monitoring them. 

Q It is necessary to track assumptions to assess their 
impact on the project and to track their 
management to be able to challenge them and to 
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develop contingency plans should they prove to be 
invalid. 

- Assumptions can be simply monitored by regularly 
reviewing them with the project team. 

- In these reviews a PM should ensure that actions 
are given to follow up any questions arising, and 
that these actions are tracked. 

Q By doing this task a PM reduces the likelihood of an 
assumption becoming the accepted wisdom. 

J Initial assumptions are rarely static and as a project 
evolves, assumptions will be proven true or untrue. 

- A PM can limit the impact false assumptions will 
have on a project by managing them. 

- To manage assumptions a PM can use the Risk 
Management Process. 

Q The project team should ask what would it mean to 
the project if the assumption turned out to be false. 

- By asking “what would it mean” the project team are 
understanding the impact if the assumption was 
false. 


_ By asking “if the assumption turned out to be false” 
the project team are gaining an understanding of the 
probability of the assumption being false. 

„ Now that a project team has an assessment of 
impact and probability for the assumption being 
false, they can record it in the risk register as a risk, 
and use the risk management process to keep track 
of it. 

5) Review 

- Once a project is complete, assumptions should be 
reviewed as part of an overall "post-project" review 
process, to evaluate all steps taken for identification, 
assessment, incorporation and control. 
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Assumption Classifications 

□Scope 

□Schedule 

□Budget 

□Resources 

□Expectations 

□Sponsorship 

□Customers 

□Technologies 

QThird Parties 

□Other assumptions 


Constraint Classifications 

Q Schedule 
Q Budget 

□ Resources 
Q Skill Levels 
Q Dependencies 

□ Legal 
Q Policy 

Q Technology 
□Other Constraints 


Best Practices For Assumption 
Management 

. Assumptions need to be specific and manageable 
and should be based as much on fact as is 
reasonably possible at the time that the assumption 
is made. 

- It is vital that areas of uncertainty are recorded and 
the accuracy of the assumption is increased as 
more data becomes available. 

w Assumptions need to be monitored and managed 
throughout the project life cycle on an on-going 
basis in order to review and test any assumptions 

- Managing assumptions is directly tied to managing 
risks because they both relate to unknowns. 

0 It is a best practice to perform a quick review of key 
assumptions at the same time you are updating the 
risks 

- Assumptions should be reflected in the Risk Log 
and reviewed at regular risk meetings 

- The Risk Log provides a standard means for 
recording assumptions and how they were derived; 

- Determining the ownership of the assumptions 


0 Evaluating the stability of and impact on the project 
if any of the assumptions prove to be true or false; 

~ Defining the actions necessary to progress and 
monitor the assumptions; 

- Making provisions for conflicting assumptions; and 

- Scheduling when assumptions are to be validated 
and reviewed throughout the life of the 

- After a project ends, assumptions may need to be 
reviewed as they could negatively impact the post- 
project benefits realisation process. 
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Issue Management 


“Even if you are on the right 
track, you will get run over if 
you just sit there.” 

— Will Rogers 


Issue Management 
Overview 


In the life cycle of any project, there will always be 
unexpected problems and issues that arise. When 
these issues arise, a project manager has to be ready 
to deal with them or they will potentially affect the 
project's outcome. 

© Issue management is the process of identifying and 
resolving issues. 

- Problems with staff or suppliers, technical failures, 
material shortages - these might all have a negative 
impact on your project. 

v Unresolved issues can be a source of conflict that 
delays or prevents the project team from attaining 
project goals, milestones, and deliverables. 

© Issue Management is designed to minimise the 
negative effects of issues on a Project. 

© Issue Management follows many of the processes 
applicable to risk management and these two areas 
are usually considered in tandem. 


© Issues arising should be recorded on a Project 
Issues Log. 

© Issue Management addresses obstacles that can 
hinder project success. 

, These obstacles can include such factors as: 

¥ Differences of opinion 

¥ Situations to be investigated 

¥ Unanticipated responsibilities. 

- The purpose of issue management is to identify and 
document these issues and to resolve them by 
reviewing and carefully considering all relevant 
information. 

~ Project issues must be identified, managed and 
resolved throughout the project in order for the 
project to be successful. 

© Issue management plays an important role in 
maintaining project stability and efficiency 
throughout the project lifecycle. 

- It is the responsibility of the project manager to 
effectively manage and monitor issues on a regular 
basis, follow up with issue owners to ensure 
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progress is being made towards resolution, and to 
report on the status of issues. 

9 In addition to overcoming obstacles to success, 
effective issue management also contributes to 
having constructive working relationships among the 
project stakeholders, including the project team. 

0 The issue log is a key tool for the project manager in 
the ongoing tracking and monitoring of issue 
resolution. 


Issue Definition 


An issue is basically anything that might affect the 
project meeting its goals. 

- An issue is problem that will impede the progress of 
the project. 

- An issue is a point or matter in question or in 
dispute, or a point or matter that is not settled and 
is under discussion or over which there are 
opposing views or disagreements. 

Risk Definition 

A risk is a potential occurrence whereas an issue is 
something that has actually occurred. 

A risk is an uncertain event or condition that, if it 
occurs, has a positive or negative impact on a project’s 
objectives. 
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Key Issue Questions 

9 How will a PM assign responsibility for resolving the 
issue? 

- How will a PM know when to escalate an issue to 
management or the steering committee? 

- Which criteria will determine an issue's priority 
status? 

. Who will set the target resolution date? 

- How will issues be communicated within the team? 

- How will a PM identify different issues if several 
occur during one project? 

Q If change orders are needed, how will those be 
handled? 

- When the resolution affects the budget or schedule, 
what will the update process be, and who will be 
responsible? 

Issue Types 

9 Issues can be raised by anyone associated with the 
project and a clear process for raising them should 
be widely publicised. 


Define the categories of issues that you're likely to 

encounter. This helps you track issues and assign the 

right people to resolve them. 

Issues may arise from a wide variety of sources, 

for example: 

- Technical issues relating to a technological problem 
in the project. 

Q Technical requirements have changed. 

^ Project is insufficiently funded. 

Q Lack of visible management sponsorship for the 
project. 

Q Ineffective project communications. 

^ Poor definition of project goals, scope, requirements 
and deliverables. 

w Project management processes not adhered to. 

w Business process issues arising from a project's 
design. 

^ Business requirements have changed. 
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- Change management issues to scope and 
timescales that arise from an unplanned requested 
change to the system. 

„ Resource issues to people problems and availability. 

- Project team lack the skills to complete the project. 

J Issues about the size of the project team. 

- Project schedule overly aggressive. 

- Equipment delays have impacted project schedule. 

0 Third party issues or "bugs" that need to be 
reported to an external supplier. 

. Transition activity issues. 

- Budget overrun issues 

- Dependencies issues on underway within the 
organisation. 

. Stakeholders issues 

- Organisation issues 

0 Issues arising from conflicts from project staff. 
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High Level Issue Management Process 
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Why an Issues Log? 

Issues need to be recorded when they happen. A project 
manager creates an issues log as part of a RAID 
template to provide a tool for reporting and 
communicating what's happening with the project. 

This makes sure that issues are indeed raised, and then 
investigated and resolved quickly and effectively. 

Without a defined process, a project manager risks 
ignoring issues until it's too late to deal with them 
successfully. 

An issues log has some of the following benefits: 

Provides a useful tool for managing and addressing 
the issues identified before and during the project 

Q Identifies and documents actions taken to address 
the identified issues and their subsequent resolution 

- Provides the senior management with a 
documented framework from which the status of 
issues can be reported 

Q Ensures the communication of issues to key 
stakeholders 


^ Provides a mechanism for seeking and acting on 
feedback regarding project issues to encourage the 
involvement of the key stakeholders. 

When to develop a Project Issues Log? 

- The Issues Log as part of the RAID template should 
be created at the start of the project. 

Q The frequency of issues reporting will vary 
depending on the size of the project. 

- With most projects this may consist of weekly 
review of any issues that could affect progress. 

- The issues log as part of the RAID report forms an 
integral part of a project. 

The Issue Log Format 

The Issues Log records as part of the RAID Log details 
of all the issues identified at the beginning and during 
the life of the project, the action taken to address each 
issue and the subsequent results. 

This issues log should be maintained throughout the 
project and updated regularly, as existing issues are 
closed as a result of successful actions and new issues 
added as they are identified. 


36 


It usually includes: 

- Date when the issue was raised. 

- An issue reference number (ID) to identify different 

issues. 

Q A name for the Issue. 

- A brief description what the issue concerns like 

these: 

¥ Technical - Relating to a technological problem in the 
project. 

£ Business process - Relating to the project's design. 

¥ Change management - Relating to business, customer, 
or environmental changes. 

¥ Resource - Relating to equipment, material, or people 
problems. 

¥ Third party - Relating to issues with vendors, suppliers, 
or another outside party. 

Z The name of the person who raised this issue. 

Q The date the issue is assigned to someone 

- Name of the person(s) assigned to solving the issue. 


- The priority and severity of the issue. that details 
how bad the consequence would be if the issue is 
left unsolved. 

- The status of the issue: 

¥ Status - Track the progress of the resolution with a clear 
label identifying the issue's overall status. Here's an 
example: 

¥ Open - The issue has been identified, but no action has 
yet been taken. 

¥ Investigating - The issue, and possible solutions, are 
being investigated. 

¥ Implementing - The issue resolution is in process. 

¥ Escalated - The issue has been raised to management 
or the project steering committee, and directions or 
approval of a solution is pending. 

¥ Resolved - The resolution has been implemented, and 
the issue is closed. 

- A list of the actions performed before the with dates 
issue is resolved 

- What the the final resolution was to settle the issue. 

- The date when the issue is solved. 
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Always Remember the Basic Questions 



Best Practices 


- Any potential problem should be surfaced early and 
dealt with efficiently. 

~ Proactively manage issues to minimise their affect 
on a project. 

^ Make issues visible to the relevant stakeholders. 

- An issue escalation process should be determined 
as a part of the overall issue management planning 
activities and should be documented. 

- All issues, regardless of how minor they seem, 
should be centrally documented in an issue log. 

9 Issues should be stated in such a way that it is clear 
how they can be resolved. 

^ Use 'traffic lights' when reporting issues. This 
provides an easy-to-see indication of whether 
issues are under control. Traffic lights could be used 
as follows: 

r Red - Cannot continue before issue is resolved. 

* Yellow - Resolution in process, and you'll be able to 
proceed soon. 
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¥ Green - Resolution implemented, and issue no longer 
exists. 

• If a date for resolution changes, keep both the old 
date and the new date visible. This helps a project 
manager spot issues that have been on the log for a 
long time. Then you can either give them extra 
attention, or take them off the list if they're no longer 
important. 

J Issues should be prioritised, assigned specific 
owners, with next steps and due dates 
documented. Issue ownership should be 
communicated clearly to those responsible for 
action items. 

- Be mindful of the “80/20 rule”, which says that 80% 
of the project impact will come from approximately 
20% of the documented issues. Concentrate the 
majority of mitigation efforts on issues that pose the 
greatest potential threat to project success. 

- A regular review of issues and the issue log is a 
highly recommended practice. 

Q The review process should occur daily for complex 
projects and at least weekly for simple projects. 


- Open issues should be reviewed at each project 
team status meeting and progress made on the 
issues should be recorded in the issue log. 

- Closed issues should remain in the issue log as a 
historical record and to facilitate lessons learned 
activities. 

0 Encourage project team members to resolve issues 
at the lowest level possible. 

^ Engage with stakeholders in issue resolution. 

- The PM should engage personally with affected 
stakeholders with a specific issue. 

- Always look for an underlying root cause if there are 
several issues raised. Keep asking “why” is the 
project having these issues? 

^ Update work plans to ensure issue is visible and 
resolved. 

~ Update the project plan if the resolution of the issue 
has had an impact on the budget or schedule of the 
project. 
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Dependency 

Management 



Dependency Management 

A project dependency is where a task, milestone or 

activity is dependent on another task or milestone being 

completed before it can start or be completed. 

Q It is possible for a project to have 

interdependencies. This is where tasks, milestones, 
etc within the same project are dependent on each 
other. 

Z The other type of dependency is external. This is 
where the dependency is on a different project, 
programme or even business as usual. 

- Project dependencies establish the links, and the 
type of links, between all the tasks of a project. 

Q There are also dependencies with other projects. 

Q Project Managers must be able to plan for and 
manage the dependencies among tasks in their 
projects. 

w The more complex a project is the more 

dependencies there will be among project tasks that 
must be planned for. 


A project manager manage a 
project interdependencies as risks. 

Dependency Types 

Understanding the types of dependencies inherent in the 
work that needs to be completed is one of the most 
important elements of creating a strong project 
schedule. 

Q 1) Mandatory Dependencies: These are 
dependencies that are logic driven e.g. A code 
module can not be test until after it's written. 

2) Resource-based Planning Dependencies: 

These are dependencies where the task could be 
accomplished faster or sooner if you had more 
resources. 

3) Discretionary Dependencies: These are tasks 
that could be scheduled differently, but the Project 
Manager chooses to schedule this particular order. 
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4) External Dependencies: These are 
dependencies that are outside the control of the 
project team, but nonetheless must be reflected 
the project schedule. Examples of external 
dependencies include completion of a project 
milestone that is linked to the completion of a 
milestone within another project. 


The value add of a PMO is in the 
facilitation and management of 
external dependencies. This is 
especially true in larger 
organisations where multiple 
projects or even multiple 
programmes may be active at the 
same time. 


Task Dependency Relationships 

Dependency relationships are utilised to link two tasks in 
the most logical manner possible. 

. The valid relationships in MS Project are: 

¥ Finish-to-Start (FS) - This represents the default 
relationship in MS Project. If you do not specify the 
relationship, FS is assumed. This relationship is utilized to 
establish a sequential flow of work - this activity can start 
when the previous activity is completed. 

¥ Start-to-Start (SS) - This relationship is utilised when 
two activities will be launched at the same time. They 
may end at different times (depending on the duration of 
each activity), but they can start at the same time. 

¥ Finish-to-Finish (FF) - This relationship is utilized when 
the completion of two activities should be linked 
together. The two activities may start at different times 
(again, depending on the duration of each activity), but 
the completion of the two activities is coordinated. 

¥ Start-to-Finish (SF) - This relationship is seldom utilized. 
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Dependency Log 

In a similar way to the management of risks, issues and 
assumptions, the recording and monitoring 
dependencies is by using a dependency Log (as part of 
the RAID template). 

This Dependency Log should typically capture: 

~ Unique Reference to identify dependency 

9 Description to briefly describe the dependency 

9 Enabling Project Name which delivers the task or 
milestone 

¥ Task Description details of the exact task that must be 
delivered 

9 Dependent Programme Name which needs the 
task to be delivered 

* Dependent details of task that needs the delivery 

v Delivery Date of dependency that must be delivered 
by to not cause a delay in dependent project 

w Probability that dependency will not be met in required 
timeline 


w Impact of dependency not being delivered in required 
timeline 

^ Status of dependency whether open or closed, etc 
^ Owner who owns the dependency 

v Date Raised of when 


The Capturing of Dependencies 

The real skill for a PMO is identifying what are the 
dependencies as most times that are not obvious even 
when you have a room full of subject matter experts. 

Here are two suggested methods, one is more informal 
awareness workshop and the other is a process method 
taken out of Six Sigma. 

1 . Dependency Awareness Workshop 

This is a workshop that can be facilitated by a PMO lead 
where all the key stakeholders and subject matter 
experts of key programmes and projects are bought 
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together to walk through the proposed project to identify 
dependencies. 

the PMO lead will start by stating the purpose of the 
workshop which is to identify any dependencies 
between projects. 

Each project should provide a one page overview with 
the following: 

• Project name 

• Sponsor 

• Project Manager 

• Start / end dates 

• Current status 

• Business area / function 

• Overview of the project 

• Business process being changed 

• Platforms being implemented / changed 

• Key milestones 

• Key issues / risks 


0 In the workshop, Each project manager will have 15 
minutes to briefly discus their project. 

© This will allow other project managers to ask 
questions and identify potential dependencies 

- At the end of the workshop the goal is to have a list 
of potential dependencies with a set of actions 
going forward 

- After the workshop, the PMO can review the list and 
determine the milestones of where the 
dependencies exists. 

Z The PMO will then publish this list and arrange a 
follow-up workshop to review the list as a group to 
align with project managers on either side of a 
dependency to confirm and agree that the proposed 
dates are realistic and achievable. 

- The output of the follow-up workshop is to have all 
parties in agreement on the delivery dates of their 
respective project dependencies. 

© Once the dependency dates are aligned and 
agreed, the PMO will now have a clear view of 
dependencies and the associated milestones in the 
different plans. 
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* The PMO will track progress against these critical 
milestones as part of the regular meetings and 
reporting. 


2.Failure Mode Effects Analysis (FMEA) 

Q This process is an alternative to the previous 
workshop approach by adopting a best practice 
from Six Sigma. 

Q The FMEA is not a new tool. The aerospace 

industry used the FMEA during the Apollo missions 
in the 1960s. 

Failure modes and effects analysis (FMEA) is a step- 
by-step approach for identifying all possible failures 
in a design, a process, or a product or service. 

J “Failure modes” means the ways, or modes, in 
which something might fail. Failures are any errors 
or defects, especially ones that affect the customer, 
and can be potential or actual. 

J “Effects analysis” refers to studying the 
consequences of those failures. 


^ Failures are prioritized according to how serious 
their consequences are, how frequently they occur 
and how easily they can be detected. 

- The purpose of the FMEA is to take actions to 
eliminate or reduce failures, starting with the 
highest-priority ones. 

w Failure modes and effects analysis also documents 
current knowledge and actions about the risks of 
failures, for use in continuous improvement. 

^ FMEA is used during design to prevent failures. 

Q Later it’s used for control, before and during 
ongoing operation of the process. 

Q Ideally, FMEA begins during the earliest conceptual 
stages of design and continues throughout the life 
of the product or service. 

When to Use FMEA 

. When a process, product or service is being 
designed or redesigned, after quality function 
deployment. 

- When an existing process, product or service is 
being applied in a new way. 
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Before developing control plans for a new or 
modified process. 

- When improvement goals are planned for an 
existing process, product or service. 

. When analyzing failures of an existing process, 
product or service. 

Periodically throughout the life of the process, 
product or service 

FMEA Procedure 

- Assemble a cross-functional team of people with 
diverse knowledge about the process, product or 
service and customer needs. 

£ Functions that can be included are: design, 
development, quality, testing, reliability, 
maintenance, purchasing, third party vendors and 
customer service. 

0 Identify the scope of the FMEA. 

¥ Is it for concept, system, design, process or service? 

¥ What are the boundaries? 


¥ How detailed should it be? 


¥ Use flowcharts to identify the scope and to make sure 
every team member understands it in detail. 

~ Fill in the identifying information at the top of a 
FMEA form. 

0 Identify the functions of your scope. 

¥ Ask, “What is the purpose of this system, design, 
process or service? 

¥ What do our customers expect it to do?” 

¥ Name it with a verb followed by a noun. 

¥ Usually you will break the scope into separate 
subsystems, items, parts, assemblies or process steps 
and identify the function of each. 

For each function, identify all the ways failure 
could happen. 

¥ These are potential failure modes. If necessary, go back 
and rewrite the function with more detail to be sure the 
failure modes show a loss of that function. 

For each failure mode, identify all the 
consequences on the system, related systems, 
process, related processes, product, service, 
customer or regulations. 
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These are potential effects of failure. 


Ask, “What does the customer experience because of this 
failure? 

What happens when this failure occurs?” 

Determine how serious each effect is. 

¥ This is the severity rating, or S. 

¥ Severity is usually rated on a scale from 1 to 10, where 1 
is insignificant and 10 is catastrophic. 

¥ If a failure mode has more than one effect, write on the 
FMEA table only the highest severity rating for that failure 
mode. 

For each failure mode, determine all the potential 
root causes. 

¥ Use tools classified as cause analysis tool, as well as the 
best knowledge and experience of the team. 

¥ List all possible causes for each failure mode on the 
FMEA form. 

For each cause, determine the occurrence rating, 
or O. 


¥ This rating estimates the probability of failure occurring 
for that reason during the lifetime of your scope. 

¥ Occurrence is usually rated on a scale from 1 to 10, 
where 1 is extremely unlikely and 10 is inevitable. On the 
FMEA table, list the occurrence rating for each cause. 

0 For each cause, identify current process controls. 

v These are tests, procedures or mechanisms that you 
now have in place to keep failures from reaching the 
customer. 

¥ These controls might prevent the cause from happening, 
reduce the likelihood that it will happen or detect failure 
after the cause has already happened but before the 
customer is affected. 

0 For each control, determine the detection rating, 
or D. 

* This rating estimates how well the controls can detect 
either the cause or its failure mode after they have 
happened but before the customer is affected. 

¥ Detection is usually rated on a scale from 1 to 10, where 
1 means the control is absolutely certain to detect the 
problem and 10 means the control is certain not to 
detect the problem (or no control exists). 
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£ On the FMEA table, list the detection rating for each 
cause. 

J Is this failure mode associated with a critical 
characteristic? 

¥ (Critical characteristics are measurements or indicators 
that reflect safety or compliance with government 
regulations and need special controls.) 

¥ If so, a column labeled “Classification” receives a Y or N 
to show whether special controls are needed. Usually, 
critical characteristics have a severity of 9 or 1 0 and 
occurrence and detection ratings above 3. 

~ Calculate the risk priority number, or RPN, 
which equals SxOxD. 

¥ Also calculate Criticality by multiplying severity by 
occurrence, SxO. 

§ These numbers provide guidance for ranking potential 
failures in the order they should be addressed. 

9 Identify recommended actions. 

¥ These actions may be design or process changes to 
lower severity or occurrence. 

¥ They may be additional controls to improve detection. 


¥ Also note who is responsible for the actions and target 
completion dates. 

As actions are completed 

¥ Note results and the date on the FMEA form. 

¥ Also, note new S, O or D ratings and new RPNs. 

NOTE 

The use of FMEA is not for the feint hearted. Reactions 
within organisations around the use of FMEA vary from 
"waste of time, lack of support" and "don't want anything 
to do with it" all the way to "powerful tool, effective way 
to prevent problems" and "needs to be done across the 
board." 

For an organisation to use FMEA successfully, the 
following must be in place: 

3 An effective FMEA process 
3 Strong management sponsorship 
w Best -practice FMEA application 
- Trained and experienced FMEA resources. 
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FEMA Form Template Example 


Function 

Potential 

Potential 

S 

Potenfcal 

0 

Current 

D 

R 

c 

Recommended 

Responsibly 
and Target 

Action Results 




Faiure 

Effects) 


Cause(s) 


Process 


n 

n 

Acfion(s) 











P 

R 

Action Taken 

S 

0 

n 

R 

C 

R 


Mode 

of Faiure 


of Faiure 


Controls 


N 

i 


Completion 

L/ 

P 










T 


Date 





N 

1 

T 

Dspense 

Does not 

Customer 

a 

Out of cash 

5 

internal low- 

5 

200 

40 









amount of 

dispense cash 

very 




cash alert 












cash 

repeated 


dissatsted 


Machine jams 

3 

internal jam 

10 

240 

24 









ty customer 


incorrect enry 
to demand 




alert 














depost system 


Rower failure 
dunng 

2 

None 

10 

160 

16 











Discrepancy m 
cam balancing 


transaction 















Dispenses too 

Bank loses 

6 

ails stuck 

2 

Loading pro- 

7 

84 

12 










much cam 

money 


together 


cedure < riffle 
ends of stack) 














Discrepancy 
in cash 


Denominations 

3 

Two- person 

4 

72 

16 











balancing 


in wrong trays 


visual 

ventcation 













Takas too 

Customer 

a 

Heavy 

7 

None 

10 

210 

21 










long to 

somewhat 


oompuler 















dispense cash 

annoyed 


network traffic 


















Rower 

interruption 

dunng 

transaction 

2 

None 

10 

60 

6 










49 


10. Calculate the resulting RPNs. 
9. Take action. 


8. Develop the Action Plan. 
7. Calculate the RPNs. 


6. Assign Detection Rankings. 
5. Assign Occurrence Rankings. 

4. Assign Severity Rankings. 

3. List potential effects of failure. 

2. Brainstorm potential failure modes. 

1. Review the process. 


50 


